rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 1 dlp-rf1 & DLP-RF1-Z usb / rf oem transceiver module the DLP-RF1-Z combines a usb interface, freescale? mc13193 2.4ghz direct-sequence spread spectrum rf transceiver ic and freescale mc9s08gt60 microcontroller to form an ieee 802.15.4 compliant, zigbee? ready, short-range transceiver module. the mc9s08gt60 microcontroller is preprogrammed with dlp design?s serial interface packet processor (sipp? firmware) for accessing the transceiver functions via simple serial calls. the application programming required for accessing the module via usb is functionally identical to that used to access the rs232c ports on a standard windows/linux/mac pc via the use of royalty-free virtual com port (vcp) drivers. (no usb driver development is required for most applications.) the sipp firmware in the dlp-rf1 resides at the application layer and is based on freescale?s smac. the sipp firmware provides basic access to dlp-rf1 functionality: packet receive and transmit, transceiver settings, eeprom access, etc. the mc9s08gt60 can be reprogrammed (if desired) with user-supplied firmware via a 6-pin bdm header that is compatible with the p&e usb-ml-12 and other device programmers (purchased separately). application areas: ? remote control and wire replacement in industrial systems ? wireless sensor networks ? home automation and control ? factory automation ? heating and cooling systems ? inventory management and rfid tagging ? human interface devices ? remote entertainment control ? wireless toys features: ? all operational power taken from the host pc ? range: >500 feet (outdoor line of sight) ? microcontroller pre-programmed with sipp firmware ? default reset via shorting two jumpers at power-up ? carrier-sense, multiple-access technology ? royalty-free usb drivers ? usb interface programming as easy as rs232c ? agency approvals for immediate deployment in the us, canada, & europe ? modular approval ? no additional agency testing required under certain conditions
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 2 1.0 system overview using the pre-programmed sipp firmware, the dlp-rf1 can be used in conjunction with other dlp-rf1 and/or dlp-rf2 modules to form simple point-to-poi nt and star configuration systems. both the dlp-rf1 and the dlp-rf2 can serve as host/system controllers. in the case of the dlp-rf1, the host is a user-supplied windows, linux, or mac pc that is accessed via a usb interface and user-supplied, 6-foot usb cable. in the case of the dlp-rf2, the host is a user-supplied microcontroller/ dsp/fpga/etc. that is accessed via a 2-wire serial interface?tx, rx, and ground. a host processor is not necessarily required by the dlp-rf2. the sipp firmware within the dlp-rf2 can be used to both gain access to the mc9s08gt60?s port pins for basic digital i/o as well as offer a few hardware-specific functions. the dlp-rf1 can be used in conjunction with other dlp-rf1/dlp-rf2 transceivers as well as other mc13193-based transceivers to form complex point-to-point and star networks. in a system using the preprogrammed sipp firmware , each transceiver has a unique 16-bit id yielding a theoretical maximum of 65,535 transceivers. every data packet handled by the sipp firmware must contain, at minimum, the number of bytes in the packet, the destination transceiver id (packet destina- tion), the source transceiver id (packet origin), and a command byte. as shipped from dlp design, the dlp-rf1 has an id of 1. if more than one dlp-rf1 is to be used in a system, then this id must be changed to a value higher than 2 (the dlp-rf2 has a default id value of 2). upon reset or power up, the id is read from non-vola tile (eeprom) memory. if jp1 is shorted at power up (or before a reset), the default id for the dlp-rf1 is set to 1, and other transceiver settings are also returned to a default state in the eeprom. (refer to section 2.2 for additional details.) 2.0 preprogrammed serial interf ace packet processor (sipp) firmware the source code for freescale?s smac is available as a free download from www.freescale.com . the sipp firmware is based on the smac. a test program (dlp-rftestap.exe) is available as a free download from www.dlpdesign.com that makes easy work of setting up the dlp-rf1 transceiver and testing its basic functionality. use of the dlp-rftestap.exe requires a usb interface between a host windows pc and the dlp-rf1 as well as a user-supplied 6-foot usb cable. **under this communication protocol, it is the responsibility of the host application to ?retry? transmissions that do not produce the anticipated reply.**
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 3 2.1 packet structure each sipp firmware packet is comprised of 6 or more bytes. the following table outlines the packet structure: packet structure byte description comments 0 number of bytes in the packet following byte 0: 5-124 each packet must contain (as a minimum) the number of bytes, a destination id, source id and a command byte 1 destination id msbyte id range: 1-65535* id:1 default for new dlp-rf1 transceivers id:2 default for new dlp-rf2 transceivers id:0 reserved for broadcast to all transceivers 2 destination id lsbyte 3 source id msbyte range: 1-65535 4 source id lsbyte 5 command byte command range: 0xa0-0xdf both command packets and reply packets. every packet must have a command byte. 6 data byte(s) 0-119 bytes of data are allowed in the packet *note : each transceiver in the system must have a unique id. id:0 is reserved for broadcast packets sent by dlp-rf2 transceivers coming out of sleep mode. 2.2 reserved eeprom locations the eeprom memory is a feature of the preprogrammed sipp firmware and, as such, is only available when using the dlp-rf1 with its firmware as shipped from dlp design. the eeprom memory used by the sipp firmware consists of a block of 32 bytes that reside within the flash program memory of the mc9s08gt60. the first 10 bytes (0-9) and the last byte (31) are reserved for storing transceiver settings and checksum. byte s 10 through 30 (user area) are available for use by the user?s host software. whenever the data in any eeprom location is changed, the checksum location (eeprom location 31) is automatically updated. at power up or reset, if ever the calculated checksum for the first 31 bytes does not match the value at eeprom location 31, the default reset values for the transceiver settings are restored, and the checksum is recalculated and rewritten. the values in the user area are preserved. additionally, if jp1 is shorted at power up (or reset), the default values for the transceiver settings are restored, and the checksum is recalculated and rewritten. again, values in the user area are preserved. the following table outlines usage of the reserved eeprom locations. these values are read at power up, reset, or via sipp firmware:
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 4 eeprom contents byte description options default reset 0 my id msb range: 1-65,535 1 for rf1; 2 for rf2 1 my id lsb 0 reserved for broadcast commands 2 transceiver channel 0-15 (2.405ghz to 2.480ghz) 7 (2.440 ghz) 3 rf transmit power 0-15 (-16.6 to +3.5dbm into the balun) 15 (+3.5dbm - max power) 4 sleep time length msb (dlp-rf2 low-power mode only) range: 1-65,535: 5-second increments, 3.8 days max. for example : 1=5 seconds, 12=1 minute, 120=10 minutes, 720=1 hour, 17,280=1day 5 seconds 5 sleep time length lsb 6 wake from sleep, host command timeout after check-in (dlp-rf2 in low-power mode only) 1-128 half-seconds 2 (4 half-second intervals) 7 baud rate for rf1-z and rf2 host controller 0-2400; 1-4800; 2-9600; 3-14400; 4-19200; 5-38400; 6-128000; 7-250000 2 (9600 baud) 8 port pin bit field (dlp-rf2 only) 0x00-0xff (a6b6b5b4 b3b2b1b0) 0x80; a6 monitored 9 dlp-rf2 available features (dlp-rf2 only) bit 7 ? measures battery voltage bit 6 ? temperature sensor bit 5 ? relays bit 4 ? reserved bit 3 ? reserved bit 2 ? reserved bit 1 ? reserved bit 0 ? reserved all bits cleared; no features available 31 checksum ex-or of bytes 0-30 calculated 2.3 command set this command set is a feature of the preprogrammed sipp firmware and, as such, is only available if using the dlp-rf1 with its firmware as shipped from dlp design. packets are broken down into two primary types: command packets and reply packets. the host controller/pc originates all command packets. in the case of the dlp-rf1, the host is the user-supplied host pc and associated application program. if a command packet is received by the dlp-rf1 via usb with a destination id that matches the id stored in the eeprom of the dlp-rf1, then the mc9s08gt60 will process the packet and reply to the host pc. if the id in the packet does not match the id stored in eeprom, then the packet is intended for a different destination and is transmitted via the transceiver.
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 5 if a packet is received via the rf transceiver with the correct id, then the packet is either processed by the mc9s08gt60 or forwarded on to the host. commands between 0xa0 and 0xbf are command packets that are to be processed by the mc9s 08gt60, while commands between 0xc0 and 0xdf are reply packets and are forwarded on to the host. if a packet arrives via the rf transceiver with an id of 0 (zero), then the packet is a ?broadcast? packet intended for the system controller (the rf1/rf2 unit t hat is designated as system controller). id:0 packets are always immediately forwarded on to the host. if a packet arrives via the rf transceiver with a non-zero id that does not match the eeprom, then the packet is ignored. the only exception to this is if ?return all packets? mode is enabled, in which case the dlp-rf1 is monitoring packet traffic, and all unsolicited packets are returned to the serial host. **under this communication protocol, it is the responsibility of the host application to ?retry? transmissions that do not produce the anticipated reply.** cmd packet recipient description expected reply cmd 0xa0 mc9s08gt60 ping (no data) 0xc0 0xa1 mc9s08gt60 set transmit power level 1 data byte; range: 0-15 0xc0 0xa2 mc9s08gt60 set transceiver channel 1 data byte; range: 0-15 0xc0 0xa3 mc9s08gt60 set rf2 baud rate (rf2 only) 0xc0 0xa4 mc9s08gt60 release immediately to sleep (dlp-rf2 only) (no data) 0xc0 0xa5 mc9s08gt60 measure energy on all channels (no data) 0xc3 0xa6 mc9s08gt60 return all packets received to host (packet watch mode?no data) 0xc0 0xa7 mc9s08gt60 return only packets with correct id to host (default mode) (no data) 0xc0 0xa8 mc9s08gt60 read eeprom 1 data byte; address: 0-31 0xc4 0xa9 mc9s08gt60 write eeprom and update checksum 2 data bytes; address: 0-30; data: 0-255 0xc5 0xaa mc9s08gt60 read i/o pin, 1 data byte: port: 0-7 (rf2 only) 0xc6 0xab mc9s08gt60 set i/o pin direction, 2 data bytes: port: 0- 7, direction: 1=out, 0=in (rf2 only) 0xc7 0xac mc9s08gt60 set/clear i/o pin, 2 data bytes: port: 0-7, state: 0/1 (rf2 only) 0xc8 0xad mc9s08gt60 setup a/d, 2 data bytes: port: 0-6, mode: 0=off, 1=on (rf2 only) 0xc9 0xae mc9s08gt60 read a/d, 1 data byte: channel: 0-6 (rf2 only) 0xca 0xaf mc9s08gt60 read vbat (no data) (rf2 only) 0xcb 0xb6 mc9s08gt60 request board type (dlp-rf1, rf2), rom and rfic versions (no data) 0xcd 0xb7 mc9s08gt60 return board id (not available through rf transceiver, physical connection only) (destination id ignored) (no data) 0xcf
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 6 0xb8 mc9s08gt60 pulse high/low with delay while high (for dlp-rf2relay only; additional hardware required) 2 data bytes: relay number: 1/2, state: 0/1 (rst/set) (rf2 only) 0xc0 0xb9 mc9s08gt60 read temperature and humidity (dlp-rf2 only; additional hardware required) (no data) refer to rftestap source code for data processing details (rf2 only) 0xcc 0xc0 serial / usb generic reply or ?ack? for selected non-broadcast commands 0xc1 serial / usb check-in from dlp-rf2 due to monitored port pin input change. 2 data bytes: current i/o pin state (a6, b6:0), bit-field with bits set for the port pins that changed state (a6, b6:0) 0xc2 serial / usb check-in from dlp-rf2 due to wake from sleep (no data) 0xc3 serial / usb measured energy data, 16 data bytes: channel 0 ? channel 15 energy levels, refer to rftestap source code for data processing details 0xc4 serial / usb eeprom read reply, 1 data byte: eeprom read data 0xc5 serial / usb write eeprom reply (no data) 0xc6 serial / usb read i/o pin reply, 1 data byte: pin state 0xc7 serial / usb set direction reply (no data) 0xc8 serial / usb set/clear i/o pin reply (no data) 0xc9 serial / usb setup a/d reply (no data) 0xca serial / usb read a/d reply, 2 data bytes: atd1rh, atd1rl, voltage result = ((atd1rh << 8) | atd1rl) * vref / 1024 0xcb serial / usb read vbat reply, 2 data bytes: atd1rh, atd1rl, refer to rftestap source code for data processing details 0xcc serial / usb read temperature & humidity reply, refer to rftestap source code for data processing details 0xcd serial / usb return board type--uc rom and rf ic versions, 3 data bytes: module mode: 100:rf1, 101:rf2, rom version: divide by 10 for version, rf ic version byte 0xcf serial / usb return id, 2 data bytes: board id msbyte, lsbyte 0xd0 serial / usb generic packet send 0xd1 serial / usb generic packet reply example : below is a simple c program illustrating the ping (0xa0) command. this assumes the presence of a transceiver with an id of 1 issuing the ping command and a second transceiver with an id of 0x13 (19 decimal) to receive and respond to the ping command:
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 7 int m_destid = 0x13; int m_sourceid = 0x01; unsigned char rx[126], tx[126]; int pos=1;//init packet index tx[pos++] = (unsigned char)((m_destid &0xff00)>>8); //destination id msb tx[pos++] = (unsigned char)(m_destid&0x00ff); //destination id lsb tx[pos++] = (unsigned char)((m_sourceid&0xff00)>>8); //source id msb tx[pos++] = (unsigned char)(m_sourceid&0x00ff); //source id lsb tx[pos++] = 0xa0;//command byte: ping tx[0] = pos-1;//assign number of bytes in packet to position zero putbuffer(tx, pos);//send tx out serial port (actually usb) getbuffer(rx, 6, timeoutwait); //wait up to timeout for 6 bytes to return if(rx[5] != 0xc0)//if buffer position 5 is not the expected reply (0xc0) { //no reply to the ping command //either retry the command or process the error } 2.4 antenna switch control the antenna switch used on the dlp-rf1 is of single-pole, double-throw configuration and is controlled by microcontroller port pins. when port pin pta7 is low, the switch is in transmit mode and the rf is passed from the mc13193 pa output to the antenna. when port pin pta7 is high, the switch is in receive mode and the antenna is connected to the receiver input. if using the sipp firmware as shipped from dlp design, the dlp-rf1 will set the correct mode automatically. this information is only made available in the event that the user wishes to reprogram the microcontroller with custom firmware. port pin pta7 tx mode 0 rx mode 1 3.0 usb interface the vcp (virtual com port) usb drivers can be downloaded from the bottom of the page at www.dlpdesign.com . [windows xp (sp1 or later) and linux (kernel 2.4.0 or later) users do not need to download drivers as they are already part of the operati ng system.] unzip the drivers into a folder on the pc?s hard drive. the usb driver installation proce ss is initiated by connecting a dlp-rf1 to the host pc. when prompted, point the driver installer to the folder in which the vcp drivers reside. the dlp-rf1 uses a usb interface design similar to that used by the dlp-usb245m usb adapter module in that the connection between the usb ic and mc9s08gt60 consists of 8 data lines and 5 hand-shaking lines. the dlp-rf1 uses a usb interface design similar to that used by the dlp- usb232m usb adapter module in that the connec tion between the usb ic and mc9s08gt60 consists of the tx, rx, cts and rts lines. once the vcp drivers are installed, the dlp-rf1 appears to the host pc as a com (rs232c) port. look in device manager to determine the com port number that is assigned to the dlp-rf1 module. the application program running on the host pc simply has to open what appears to be an rs232c port then build and send a packet to gain access to/control of the dlp- rf1. the vcp drivers intercept the data packets on their way to the rs232c com port and reroute
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 8 them to the usb port. all packets returned from t he dlp-rf1 simply appear in the receive buffer that was created when the com port was opened. the host application must set the baud rate to 9600 baud if using the DLP-RF1-Z. this baud rate can be changed by the host application once connection has been made to the rf1-z. there is no need for the host application to set the baud rate of the opened com port to the dlp-rf1. since the host application is responsible for ?retrying? any command packet that goes unanswered, the host application must wait an appropriate amount of time for all responses. the amount of time to wait for a reply is dependant upon several factors so it is best for the user to derive empirically (trial and error) the appropriate amount of time to wait.
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 9 4.0 regulatory agency considerations 4.1 agency identification numbers compliance with the appropriate regulatory agencies is essential in the deployment of all transceiver devices. dlp design has obtained modular approval for this rf product such that an oem need only meet a few basic requirements in order to utilize their end product under this approval. corresponding agency identification numbers are listed here: part number us/fcc can/ic dlp rf1 sx9000rf1 5675a-000rf1 4.2 integral antenna the dlp-rf1 is approved for use with the integral antenna only. modifying the dlp-rf1?s pcb antenna or modifying the pcb to use an external antenna will void all agency compliance. 4.3 fcc/ic requirements for modular approval any changes or modifications to the dlp-rf2?s printed circuit board could void the user?s authority to operate the equipment. 4.3.1 warnings operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesirable operation. this device is intended for use under the following conditions: 1. the transmitter module may not be co-located with any other transmitter or antenna. 2. the module is approved using the fcc ?unlicensed modular transmitter approval? method. as long as these two conditions are met, further transmitter testing will not be required. however, the oem integrator is still responsible for testing their end product for any additional compliance measures necessitated by the installation of this module (i.e. digital device emissions, pc peripheral requirements, etc.). note : in the event that these conditions cannot be met (i.e. co-location with another transmitter), then the fcc authorization is no longer valid and the corresponding fcc id may not be used on the final product. under these circumstances, the oem integrator will be responsible for re-evaluating the end product (including the transmitter) and obtaining a separate fcc authorization.
rev 1.5 (november 2005) dlp-rf1/z ? dlp design, inc. 10 4.3.2 oem product labeling the final end product must be labeled in a visible area with the following text: ?contains tx fcc id: sx9000rf1? 4.3.3 rf exposure note : in order to comply with fcc rf exposure compliance requirements, the antenna used for this transmitter must not be co-located or operating in conjunction with any other antenna or transmitter. 4.3.4 additional information for oem integrators the end user should not be provided with any instructions on how to remove or install the dlp-rf1. 5.0 disclaimer neither the whole nor any part of the information contained herein nor the product described in this datasheet may be adapted or reproduced in any material or electronic form without the prior written consent of the copyright holder. this product and its documentation are supplied on an as-is basis, and no warranty as to their suitability for any particular purpose is either made or implied. dlp design will not accept any claim for damages whatsoever arising as a result of use or failure of this product. your statutory rights are not affected. this product or any variant of it is not intended for us e in any medical appliance, device, or system in which the failure of the product might reasonably be expected to result in personal injury. this document provides preliminary information that may be subject to change without notice. 6.0 contact information dlp design, inc. 1605 roma lane allen, tx 75013 phone: 469-964-8027 fax: 415-901-4859 email: support@dlpdesign.com internet: http://www.dlpdesign.com
|
